Ops JAWS Meetup#23 オブザーバビリティの現在地と未来 パネルディスカッション 開催報告 #opsjaws

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

2023年3月31日 Ops JAWS Meetup #23 を開催しましたのでサマリー報告いたします。
本エントリは敬称略で記述しております。ご了承ください。

イベント概要はこちらです。

動画アーカイブはこちらです。見逃してしまった方は是非ご覧ください。サマリーに記載していないディープな話も楽しいですよ。

パネリスト紹介

白鳥 翔太

東日本電信電話株式会社（NTT東日本）ビジネス開発本部　第一部門クラウドサービス担当

facebook: shota.shiratori0707
2009年入社。ネットワークエンジニア～セールス職を経て、2018年よりクラウドサービス担当に勤務。クラウドインテグレーション&MSPサービスを立ち上げ、現在は同サービスチームのマネージャを務める。

九龍真乙 (くりゅうまおと)

OpsJaws/New Relic

Twitter: qryuu
Zabbixの日本におけるテクニカルサポート、テクニカルトレーニングの立ち上げを行い、VMwareベースのクラウドサービス開発、AWSテクニカルサポート、クラウドアーキテクトを経てNewRelic シニアテクニカルサポートエンジニア。
テクニカルサポート、テクニカルトレーニング、運用コンサルを専門領域としてお客様の運用負荷軽減を目指す。得意分野は運用設計、クラウド設計、OSSソフトウェア。

清水 勲

株式会社 MIXI Vantageスタジオ みてねプロダクト開発部 SREグループ

Twitter: isaoshimizu
約8年間 SIer にて勤務した後、2011年株式会社ミクシィ（現 株式会社MIXI）に入社。SNS「mixi」のインフラ運用、モンスターストライクの SRE を経て、2018年に子どもの写真・動画共有アプリ「家族アルバム みてね」の SRE チームを設立。2022年より SRE グループのマネージャーを務める。

濱野 悠介

株式会社 MIXI 開発本部 CTO 室 SRE グループ

Twitter: yhamano0312
新卒で SIer に入社し、主にパブリッククラウドに関する設計/構築/運用を担当。2020年に株式会社ミクシィ（現 株式会社MIXI）に入社し、主にバックエンドエンジニアとして複数プロダクトにて機能開発や SRE 活動支援を行っている。

1 オブザーバビリティと聞いて何を思うか？

白鳥
オブザーバビリティと聞いて思うのは非常にユーザーというか使う側に寄り添ったものだなというふうに思います。

九龍
監視って IT インフラのことは監視で足りたんです。けれども、今のマイクロサービスであったりですとか、コンテナであったりですとかっていう環境で監視だとどうしても足りない。そこを運用していく開発していくためにはこのオブザーバビリティを持っていくということが非常に重要。 というかそもそもないと多分運用も回らなくなりますというものだと思ってます。

清水
サービスに関わってきた中で、オブザーバビリティになにが欠かせないかって考えるとやっぱり APM がものすごい重要なんだろうなっていうのは思います。 いろんなメトリクスだったりログだったりトレース情報みたいないろいろあると思うんですけど、その辺を組み合わせてオブザーバビリティだなって感じることは多いかなと思います。

濱野
私個人的な感想だと3～4年前からいろんなところで聞けるようになってきて、理由としては多くの企業さんでクラウドネイティブの技術みたいのを採用しだしたところが出てきて、 やっぱりそういったクラウドネイティブなところだと必須になってくるのでそういったオブザーバビリティの重要性、必要性というのが重要になってきた時期なのかなと思っております。

2 モニタリングとオブザーバビリティを使い分けていますか？

清水
それぞれ使ってますみたいな感じになってて、例えば Aurora の CPU 利用率を日々モニタリングしてますみたいなのは欠かせないことだと思っています。
一方でそのアプリケーションの状況とか見たいよねって時にオブザーバビリティってやっぱり必要になってくる。そのトラブルシューティングをするときにいざこう調べようと思ったとき、ログがない、メトリクスも保存されてないみたいなことになっちゃうとそれはオブザーバビリティないじゃんってなると思うので。

九龍
逆に言うと、ツールを皆さん考える時にモニタリングツールとオブザーバビリティツールって同じようで実は違うって思っていただきたい。
モニタリングツールはモニタリングツールで非常に進化してきているんでモニタリングツールでできることを オブザーバビリティツールでやろうとした時に実はやりにくい部分っていうのもあったりします。
アプリケーション部分が見えなかった実際のユーザー体験は見えなかったりという部分がある、 そういった部分を把握するのがオブザーバビリティツールの役割であって、局所最適化的に自動化していくとかだったらモニタリングツールの方が合っている。 モニタリングツールとオブザーバビリティツールをうまく併用してもらった方が運用の現場はハッピーになるし開発者は全体像がつかめるという風になると思ってます。

3 モニタリングに適した場所は？オブザーバビリティに適した場所は？

白鳥
モニタリングに適した場所って物理的に壊れる領域だと僕は思ってます。 壊れる前に予兆もモニタリングで検知して、決めた対応で取りに行く、人の対応が必要でなかなか自動化が難しいという領域なのかなというふうに思っております。 一方でオブザーバビリティは全体構造を理解して、どこって特定していったりていうところがいいのかなと考えています。

4 開発サイクルにおけるオブザーバビリティの活用

濱野
開発環境とか用意する際にその中でもメトリックスログとかトレースをとっておくと、実際に開発者自身でデバッグしたり、QA の段階でバグが見つかってその修正をする時に どこが原因でバグになってるのかを見つけやすくなるで、開発サイクルがオブザーバビリティを入れておくと速くなるところがあると思います。
負荷試験でも負荷をかけていきますが、実際にどこが問題になってるかを発見したりするので、活用できる場面が多いのかなと思います。

九龍
開発者さんが開発していくコーディングツールの中にオブザーバビリティで収集した結果を統合するツールがあって、 どうなるかって言うとテストをしていてエラーが出たとかパフォーマンス上の問題が出たっていう時にそれはコードのここですよっていう指摘までします。 そうするとじゃあ問題が見つかりましたで開発のところでそのに対応するコードを頑張って探すんじゃなくて、そこの紐付けまでやってくれるんであとはここのコードだよと指摘されたところを開発者は直してもらうという形。
無駄な労力かけずに開発サイクルを上げていっていただくというのが開発におけるオブザーバビリティと思っております。

5 浸透していますか？

白鳥
2つサイドがあって、自社の話とお客様の話があると思っています。
自社の話で言うとクラウドで開発をしてるメンバーっていうのは徐々に浸透し始めてきてるなっていうところの実感はある一方で、 ネットワークのところはまだまだモニタリングが合うというところなので、こういった概念はこれからかなというところではあります。
お客様のところだと二極化するのかなって思います。まだまだそのオンプレだったり、今までのベンダーに頼っていたところで少しずつ変えていく、組織を変えていく中で少しずつ浸透していくとは思います。

清水
うちの組織に関しては割と浸透してきたなあというのは実感としてあるんですけど、まだ足りないところももちろんあって、 開発者がデプロイして開発者がすぐに APM を確認するとか、パフォーマンス上問題ないかとかそういうのは割と一般的になってきてるっていうところが現状ある。
ただ開発者だけでいいのかみたいなところもあるので、ビジネスサイドも見れるようにところはまだまだちょっと不足してるかもしれないなっていうところありますね。

吉井「高すぎるのが壁になったりしますか？」
清水 壁ですね。(会場爆笑)
いやただそのコストに対する価値は大事だと思うんです。かけるべきところはコストかけるべきっていうのがあると思うので、そこに対してのそのメリットがどれだけあるのかを表現できるかとか体感としてあるかみたいなところがある程度ないと高く感じてしまうのはあるかなと思います。

九龍 オブザーバビリティの浸透と SRE の浸透ってニアリーイコールですか？

清水
そうですね何でしょうね、SRE の方が先に流行りだした気がするので、オブザーバビリティは理解はある程度されてるかもしれないが、本当に広がってるかっていうとまた別の話かもしれないですね。

6 オブザーバビリティはオーバーテック？

濱野
各社クラウドベンダーだったりとか商用ツールの方でオブザーバビリティツールいろいろ出されてると思うんですけど、日々アップデートがどんどんどんどん出てくるのでキャッチアップするのが大変、すごい便利な機能が出たんだけどなかなか使いこなせない、そんな機能あったんだみたいなのが結構あったりするんで、そういったところにオーバーテックなのかインプットするのが難しいなみたいなのは結構感じています。

白鳥
ちょっと難しいんですけどオーバーテックって感じる人がどういう人かなっていうのちょっと今聞きながら考えたんですけど、 やっぱりそのベンダーに委託したいとか IT のことはあんまり理解したくないとか、こっちの MSP でよしなににやってくれって感じの人に オブザーバビリティを一生懸命やっても難しいと捉えちゃって、で価格を見て高い何でってなってなかなか取り入れてもらえないってところが難しさはあるのかなというふうに今感じているところですね。

九龍
オブザーバビリティはインフラの人たちに分かりやすく言おうとすると多分 SNMP はモニタリングなんですね。 ネットワークパフォーマンスモニタリングって SNMP は補助的に集めるんですけどメインはネットフローなんですね。
その機器によって流れているパケットとかトラフィックはどうかっていうのを見ていくっていうのがオブザーバビリティでありネットフローの技術だったりするんです。
そうなってくると機器が壊れたら対応してほしいという人たちにとってはオブザバビリティーオーバーテックなんですね。 でネットワークを快適にしたいって思う人たちとかソフトウェアを快適にしたいって思う人たちにとってはオブザービリティって必要な技術だと思うんです。

7 オブザーバビリティの教育

清水
さっきの組織内に広めてくっていうところがある意味教育かなと思うのと、そのツールの使い方とかパッとアカウントを渡して使ってくださいと言われて使える人ってそこまで多くない。
徐々に画面見せながらとかドキュメント書いたりしてこう教えていくっていうのはまあ最低限必要かなと思ってやったりしてます。
この本読んでね、みたいになると進まないかなと思うんですよ。全部読める人そんなにいないと思うのでなので、こう噛み砕くとかわかりやすく教えるみたいのはちょっとずつやってたりします。

濱野
僕は教育するというか結構教育されてきた立場だと思っていて、オブザーバビリティが活用されて開発が回ってるところに実際入ってみるのが重要かなと思っています。
mixi 入るといろんなプロダクトでオブザーバービリティ活用されてて、障害調査とかものすごくやりやすくて感動したのを覚えています。
次の現場とかで仮にオブザーババビリティがあまり導入されてないってところに入ったとしても、自らツール導入していって、さらにそれを他のメンバーが見て広がっていくみたいなことがあると思います。

8 モニタリングが完成しているチームにオブザーバビリティを持ち込むか？

九龍
そもそもモニタリングが完成することがあるのか今のビジネスにおいて。ということがありまして、 昔のようなウォーターフォールでシステム開発しました出来上がりましたでこれを5年間塩漬けで運用しますよっていう現場だったらモニタリングって完成する可能性が あるとは思うんです。
けど、mixi さんみたいに SaaS だったら日々変わっていってどんどん新機能が出て、新しいサービスのためにデバイスが追加されたりユーザーの種類が増えていく環境でモニタリングって完成するんでしょうか？
動的に対応し続けるモニタリングってそれは多分追いつけない。

吉井「白鳥さん、どうですか？塩漬けシステムよく見ると思うんですけど」

白鳥
塩漬けシステムだらけなんですけど、日々やっぱり戦いなんですよね。
このモニタリングが完成してるチームがベースにあって、そこからそれをクラウドでやっていこうとなってきた時に、どうしても外部の環境とかお客様の環境は変わっていくし、こうやって世の中に SaaS や DevOps が浸透してくる中で、ある意味 MSP ってこのままやると下手するともうなくなる市場かもしれないっていうそういう危機感を持って仕事をすると、もちろんモニタリングのスキルは必要なんだけれども、オブザーバビリティであったり自分の経験や知見をお客様に提供する今度これから求められている Ops のチームの価値なんだよっていうところ進めているような形にはなってます。

9 商用ツールを使うか？ CloudWatch/X-Ray/AMP/AMG で頑張るか？

濱野
組織とかそのチームの状況にもよるかなと思ってて、コストやどういった機能を使っていきたいかに関係してくると思うんです。
商用ツールだと便利な機能だったり痒いところに手が届くような便利な機能がたくさんあるので、そういったところが商用ツールのメリットと思います。
適材適所で商用ツールとマネージドサービスを使い分けるみたいなところも一つの手だと思います。

清水
サービスの規模が小さい頃はこのツールで良かったねってやっぱりあったんですよね。で増えてくると情報量が多いのでログを全部商用サービスに置くっていうのはなかなかこう決断しづらいところがあって、コスト的なところですね。なのでまあ一旦はこっちに別のツールを使いましょうでコストを下げておきましょう、問題解決もある程度できる状況でなので結構分けているんですよね。
ただでも理想はやっぱりこう全部統一されてるのが楽なんですよ。全部紐付かれてトラブルシューティング楽なんで。ただ理想と現実は違うっていうところがあります。

九龍
AWS ってやっぱりパーツが揃っているパーツ屋さんなんですよね。だから AWS でオブザービリティやろうとすると自分で色々組み合わせて頑張ってくださいということになると思います。
システム全体を自分で頑張るんじゃなくて自動的に紐付けて関連付けて一連のシステムとして見るという形で見ていただけるというのが、商用ツールの売りである部分なので、そこの全部混ぜる関連性を本当に違う領域同士を横断的に見るっていうのをどこまで頑張るのか、頑張らないのかって違いだろうなと思います。

白鳥
自社がどうかっていう話は置いといて、MSP という観点で言うと圧倒的に商用ツールですね。
まず楽して導入、スタートさせたいっていう観点と、ある程度の品質を一定のレベル以上は保っておきたいっていう時を考えてあげると商用のツールというのは助かります。

以上、吉井 亮 がお届けしました。